Modernly, the use of PCs (personal computers), increasingly including so-called laptop and notebook computers, is increasingly common and the computers themselves are of increasing computer powerful, decreasing thermal power and ever more complex.
Older PCs have had a single, and overarching, control software, usually a Windowing O/S (Operating System) for example Microsoft® Vista® (a commercial product) or Linux® with GNOME (an open source program).
Commercial Windows® products and open source O/Ses each have distinctive advantages, increasingly buyers of laptop computers wish to have, and use both. Simultaneous provision of multiple O/S program products on a single computer raises various challenges including multi-boot, ACPI supported loading and virtualization hypervisor programs with associated hardware support.
Another issue arises as to sharing data, and hence sharing FS (file systems), across O/Ses. This is particularly a problem where multiple O/Ses operate either in effective simultaneity or continually and alternately within a single operating session. Typically, for a PC, an operating session is from POST (Power-on Self Test) through to orderly O/S shutdown, and usually a power-off sequence. Mutexes, resource locking and similar techniques are well-known in computing where multiple entities (execution threads, processor cores, distributed processors etc) need to share data file resources effectively. Such situations in computing have commonly been resolved by co-operative software procedures to ensure orderly resource sharing, or at least orderly resource allocation. However a closed source O/S cannot be expected to facilitate resource sharing with another O/S when it has (by design) no awareness of that other O/S.
A less general solution is required where files are to be concurrently or have alternating availability between two or more O/Ses and the present invention addresses at least one such situation. In particular, where a closed source O/S implements advanced or sophisticated data handling features, for example journalizing or checkpoint/rollback, then it may appear to be not well-behaved (or at least not behaving in a well understood manner) to the other O/S. The present invention addresses one particularly commonplace situation, and more.
Previous solutions have included making each O/S take complete control of its own FS (file system) which is then seen as RO (read-only) from the other O/S. Not only is that unduly restrictive in its capabilities, but it may not even produce consistent results when a FS is left mid-session in an odd or otherwise undocumented state by an O/S that has the FS open for RW (read-write). In some cases such a FS may even be detected as un-mountable (or corrupted), even for RO, outside the context of the O/S that has RW access to it.
A significant advantage of embodiments of the invention over previously developed solutions is that it becomes possible to switch execution to and fro between more than one O/S without the need to shut down and restart file systems (and by implication restart operating systems) between switches of O/S context within a single operating session.